Las Inspecciones de Software y las Listas de Comprobación (página 2)

– La carencia de un mecanismo propio para
el control de versiones.

– No existe un grupo dedicado a la
atención al cliente, de forma que no sean los
desarrolladores quienes atiendan las solicitudes o preguntas de
los clientes que no están relacionadas con
ellos.

El proceso de software que garantice la calidad adecuada
para cualquier institución, se define de la siguiente
manera:

"Es un conjunto de actividades, métodos,
prácticas y transformaciones que las personas usan para
desarrollar y mantener software y sus productos asociados" [1]
[12].

Cuando una empresa que desarrolla software crece,
necesita ampliar su organización, para esto, algunas
veces, utilizará un modelo establecido internacionalmente
para llevar a cabo las actividades o funciones que le permitan
cumplir sus metas y objetivos con una buena calidad hacia los
clientes o usuarios. Dentro de este modelo de proceso existe un
Plan de Aseguramiento de Calidad y se define como un conjunto de
personas que están encargadas de llevar el
seguimiento, al modelo de proceso de desarrollo, dentro de la
empresa. Este plan y las personas que están a
su cargo son muy importantes para la empresa.

Lastimosamente, la mayoría de las empresas de
software hoy en día no establecen normas, ni objetivos, ni
metas, ni políticas adecuadas para lograr que los
productos elaborados cumplan; primero, normas internacionales
para llevar a cabo el mantenimiento o para la exportación;
segundo, la organización mejore incrementalmente su
conocimiento y el dominio completo, entre los desarrolladores,
sobre el proceso de software; tercero, la tecnología
utilizada sea explotada al máximo; y cuarto, se tenga un
grupo de personas que continuamente mejoren el proceso y velen
por la calidad en la vida del proyecto.

Por estas razones, han surgido modelos del proceso de
software, que se explican brevemente a continuación. Estos
modelos se utilizan en el desarrollo de proyectos de software.
Cada uno de estos establece la madurez por niveles que va
incrementándose a medida que la empresa va cumpliendo los
requisitos de entrega en tiempo de los proyectos, mejore la
capacidad de administración, alcance un conocimiento
continuo entre los desarrolladores actuales y nuevos sobre el
proceso de software, se garantice que las actividades internas
correspondan a procesos planificados, sean usables y consistentes
las actividades, los procesos se actualicen y mejoren, existan
pruebas pilotos, se realice un análisis de costo y
beneficio para el cliente, y los roles y responsabilidades
estén claros en los procesos y en la
organización.

– El Conjunto de estándares ISO-15504 SPICE
(Software Process Improvement and Capability Determination).
Desarrollado por el WG10 de la ISO (Internacional Organization
for Standardization) [59].

– ISO 9000 – 9001. La Organización
Internacional para la Estandarización, mejor conocida como
ISO, promueve la estandarización internacional, de tal
manera que se facilite el intercambio de bienes y servicios
así como el desarrollo científico y
tecnológico mediante el comité técnico
TC176, encargado de la normalización del Aseguramiento y
Administración de la Calidad. ISO 9000-3 es
una guía y no una norma, que describe los elementos
de un sistema de calidad orientado al software
[60].

– Tick-It. Es una iniciativa de la industria del Reino
Unido, que consiste en un esquema de certificación basado
en la norma ISO 9000, guía ISO9000-3. Pone énfasis
especial en la experiencia y en la capacitación que deben
tener los auditores calificados, tanto en el área de
desarrollo de software como en la evaluación de los
criterios específicos de la norma. Tick-It es un esquema
más riguroso que ISO 9000 [61].

– El Modelo de Madurez de la Capacidad (CMM: Capability
Maturity Model). Desarrollado por el Instituto de
Ingeniería de Software (SEI) de la Universidad Carnegie
– Mellon en USA. Se basa en cinco niveles de madurez de las
empresas que producen software, los niveles se enfocan en los
procesos de desarrollo, capacidad de los procesos y su
desempeño. [56]

– El Modelo de Madurez de Capacidad Integrado (CMMI:
Capabily Maturity Model Integration). El Proyecto CMMI es un
esfuerzo cooperativo del Departamento de Defensa de los Estados
Unidos y el Instituto de Ingeniería de Software (SEI). El
propósito del proyecto es proveer mejoras en costo,
cumplimiento de cronogramas y calidad de los proyectos eliminando
la complejidad de múltiples modelos de CMM. [50]
[54]

Ya que el trabajo esta dirigido para la
introducción en las empresas de los modelos CMM o CMMI, se
explica brevemente; las diferencias entres estos dos modelos para
luego señalar los niveles de madurez. También,
durante el trabajo, se comprende como juega un papel importante
las Inspecciones de Software con las Listas de
Comprobación en los distintos niveles de madurez para los
dos modelos. Hay que señalar, "que la aplicabilidad de los
modelos para la mejora de procesos depende de la situación
y del tipo de cada organización, ya que los programas de
mejora deben estar basados en la misión y los objetivos
del negocio que tenga cada organización." [52]

La introducción de un modelo de mejora es
necesario en la empresa, ya que uno de los requisitos a nivel
internacional para ser subcontratado y desarrollar software, es
estar en el nivel 3 o nivel 2 de CMM o CMMI, o tener
una certificación ISO, por esta razón la India ha
tenido un gran auge en este sentido.

CARACTERÍSTICAS DE MODELO DE CAPACIDAD DE
MADUREZ (CAPABILITY MATURITY MODEL – CMM)

CMM persigue la evaluación de los procesos de
desarrollo de software dentro de una organización
proponiendo un plan de mejoramiento en base a una serie de
niveles que van desde un proceso inmaduro hasta un proceso
disciplinado, ordenado y de mejoramiento continuo.

La madurez de un proceso de software, determina en que
grado un proceso de software es explícitamente definido,
administrado, medido, controlado y hecho efectivo. La madurez es
un indicador de la capacidad del proceso de software para lograr
sus objetivos y resultados esperados [57].

Una Empresa logra mayor madurez mediante la
institucionalización del proceso de desarrollo de
software, estableciendo las políticas, estándares y
estructuras organizativas.

CMM esta conformado por niveles de madurez, que indican
la capacidad del proceso. Los niveles, contienen áreas
claves de proceso (PKS), con la ayuda de ellas se alcanza los
objetivos. Las áreas están organizadas con
características comunes, que se aplican a la
implementación o institucionalización. Las
características comunes entre las áreas contienen
prácticas claves, que describen la infraestructura o las
actividades. [5][56]

Nivel 1 (Inicial):

No hay proceso definido para el proceso de
Software.

Nivel 2 (Repetible).

Gestión del proceso de
software: coste, planificación y funcionalidad,
sigue un conjunto de áreas.

– Administración de
Requisitos.

– Planificación de Proyectos de
Software

– Seguimiento y supervisión de
Proyectos de Software

– Administración de Subcontratos de
Software

– Aseguramiento de Calidad de Software
(SQA)

– Gestión de Configuración
del Software

Nivel 3 (Definido).

Desarrollo y Mantenimiento documentado y
Estandarizado. Definido, los procesos son
estándares en toda la empresa y se valida si éstos
son los adecuados. El conjunto de áreas es el
siguiente:

– Enfoque del Proceso de la
Organización

– Definición del Proceso de la
Organización

– Programa de Formación

– Gestión de Integración del
Software

– Ingeniería del Producto de
Software

– Coordinación entre
grupos

– Revisiones periódicas.

Nivel 4 (Gestionado).

Medidas del Producto y del Proceso.
Registro de valores de Calidad. Administración, se
establecen métricas de cada una de las partes del proceso
y se analizan sus resultados. Las áreas son las
siguientes:

– Gestión cuantitativa del
Proceso

– Gestión de Calidad del
Software

Nivel 5 (Optimizado).

Resultados cuantificados, con opción
de mejora

Los procesos se optimizan continuamente y
se definen estándares. Las áreas son las
siguientes:

– Prevención de Defectos

– Gestión de la
Tecnología

– Gestión de Cambios en el
Proceso

El modelo CMM ofrece una estrategia para mejorar el
proceso, junto con un marco para evaluar empresas. Mejorar el
proceso es establecer un rango de calidad, es una medida para
otros de cómo es llevado el proceso de Software, de esta
forma, durante el avance entre los niveles se va robusteciendo la
fabricación de software.

CARACTERISTICAS DEL MODELO DE CAPACIDAD DE MADUREZ
INTEGRADO (CAPABILITY MATURITY MODEL INTEGRATION –
CMMI)

En Diciembre del 2001, el Instituto de Ingeniería
de Software (SEI) lanzo la versión 1.1 del CMMI es una
nueva versión de CMM. CMMI es un modelo de Procesos, o una
colección estructurada de componentes que describen las
características de los procesos efectivos de software que
han sido probados por la experiencia.

También, esta dividido por Áreas de
Proceso como CMM, cada área está compuesta por
metas, cada una de estas metas está conformada por
prácticas. Las metas y las prácticas son
específicas o genéricas. Las prácticas
corresponden a una sola Área de Proceso, mientras que las
áreas específicas van a través de todas las
áreas de proceso.

Las metas y prácticas genéricas, tienen
elaboraciones que las inician para cada área de
proceso.

Las metas específicas se aplican a solo un
área de proceso, mientras que las metas genéricas
se aplican a más de un área de proceso. Una
práctica específica es una actividad considerada
importante para alcanzar una meta específica. Las
prácticas genéricas son prácticas que se
aplican a cualquier área de proceso, y que pueden mejorar
el desempeño y control de cualquier proceso.

Existen dos representaciones para este Modelo: por
etapas (Staged) [62] y continua (Continuous) [63].
La representación continua es claramente más
flexible en cuanto a que permite formar una
estrategia de mejora que se adapte a las metas globales de la
respectiva organización. La representación por
etapas, en contraste, es el modelo preferido por organizaciones
que quieren migrar más fácilmente de CMM a
CMMI.

Los niveles de CMMI a CMM tienen la misma
definición. Nivel 1 (Inicial):

No hay proceso definido para el proceso de
Software.

Nivel 2 (Administrado):

– Administración de
Requisitos.

– Planificación de
Proyecto.

– Monitoreo y Control del
Proyecto.

– Administración del Acuerdo del
Proveedor.

– Medición y
Análisis.

– Aseguramiento de Calidad del Proceso y el
Producto.

– Administración de
Configuración.

Nivel 3 (Definido)

– Desarrollo de Requisitos.

– Solución
Técnica.

– Integración del
Producto.

– Verificación.

– Validación.

– Enfoque del Proceso
Organizativo.

– Definición del Proceso
Organizativo.

– Entrenamiento Organizativo.

– Administración integrada del
Proyecto.

– Administración de
Riesgos

– Análisis de Decisiones y
Resolución.

– Ambiente Organizativo para la
Integración [62].

– Equipo Integrado [62].

Nivel 4 (Administrado Cuantitativamente):

– Desempeño Funcionamiento del
Proceso Organizativo.

– Administración Cuantitativa del
Proyecto

Nivel 5 (Optimizado):

– Innovación y Despliegue
Organizativo.

– Análisis de Causas y
Resolución

Cada uno, CMM y CMMI, establece un punto de partida para
encontrar las soluciones a los requisitos y problemas que pueda
tener una empresa de desarrollo software, logrando con estos
modelos a cumplir con sus metas y objetivos hacia el
cliente.

Sin embargo, de estos modelos descritos anteriormente en
un artículo publicado en Fortune se dice: [2]

"Un estudio más reciente del Standish Group hecho
sobre 352 compañías de software, donde se
estudiaron más de 8.000 proyectos de software, revelaron
lo siguiente:

· El 31% de todos los proyectos de
software fueron cancelados antes de terminarse

($81 billones de dólares
norteamericanos perdidos).

· El 53% de los proyectos tuvieron
un costo 189% mayor de lo estimado.

· El 9% de los proyectos se
terminaron a tiempo y dentro del presupuesto
(compañías grandes).

· El 16% de los proyectos se
terminaron a tiempo y dentro del presupuesto
(compañías pequeñas).

A raíz de estos datos, se les
preguntó a las empresas sobre las causas de estos
problemas. Las tres principales razones expuestas fueron las
siguientes:

· Falta de información por
parte de los usuarios (12.8%)

· Especificaciones y requisitos
incompletos (12.3%)

· Cambios en las especificaciones y
requisitos (11.8%)

Este estudio muestra que los defectos cometidos durante
la fase de requisitos son extremadamente caros de reparar. En
proyectos grandes, este tipo de defectos son muy frecuente. En el
estudio de un proyecto de la fuerza aérea de USA, los
defectos fueron clasificados según la fuente de donde
provenían. Se encontró que los defectos de la etapa
de requisitos comprendían el 41% del total de defectos,
mientras que los defectos en la lógica del diseño
comprendían solamente el 28% del total [2].

El problema radica en el Proceso de Desarrollo del
Software, ya que no existe un método para la
detección de defectos, que es la parte esencial para el
inicio de la mejora continua en el proceso de desarrollo. La
Inspección con las Listas de Comprobación es
necesaria para iniciar la mejora en el proceso de desarrollo, la
cual, es una herramienta alternativa, haciendo que se detecten,
la mayoría de los defectos a tiempo. Además, sin
realizar una planificación y seguimiento para llevar a
cabo esta actividad no es posible sistematizarla.

Por tanto, el objetivo general será: Permitir que
el Grupo de Aseguramiento de Calidad obtenga un modelo de
Inspección de Software que ayude a controlar la calidad
durante el proceso de software, a través de una
herramienta automatizada que usa las listas de
comprobación.

Teniendo como objetivos específicos los
siguientes:

– Establecer un modelo de inspección
de software de acuerdo a la realidad que nos rodea.

– Establecer una clasificación de
las listas de comprobación de acuerdo a las fases de un
proyecto y estándares internacionales.

– Proponer pasos para las inspecciones de
Software, haciendo uso de las listas de
comprobación.

– Desarrollar una aplicación
automatizada que refleje el modelo de inspección de
software a establecer. El cual debe ser capaz y tener las
siguientes facilidades:

o Ayudar al Grupo de Aseguramiento de
Calidad a elaborar el Plan de
Inspección.

o Registrar los resultados del Grupo de Aseguramiento de
Calidad por cada uno de los proyectos desarrollados.

o Registrar los grupos que llevan a cabo la
inspección.

o Ayudar a los programadores, a los usuarios,
administradores de proyecto, al equipo de inspección y a
los especialistas en una determinada área y fase de
desarrollo, a detectar los defectos.

o Ayudar a elaborar los grupos de
inspección.

o Registrar las Listas de Comprobación para cada
uno de los proyectos y dar alternativas para la creación
de nuevas listas.

o Capturar los defectos encontrados durante la
ejecución de las inspecciones realizadas en los distintos
niveles de desarrollo, para ayudar a prevenir los posibles
defectos y mejorar el proceso de inspección.

La hipótesis para el presente
trabajo será:

Con las listas de comprobación se puede ayudar a
realizar el proceso de Inspección de Software de forma
objetiva.

Para cumplir los objetivos y responder a la
hipótesis que el autor plantea, se realizaron las
siguientes tareas en forma cronológica en tiempo de la
siguiente forma:

– Se realizó un estudio del estado actual de las
Listas de Comprobación. Para este fin, fue hecha una
búsqueda exhaustiva en Internet y en libros relacionados
con el desarrollo de software, reflejada en la
bibliografía.

– Se estudió los distintos modelos utilizados hoy
en día para realizar el proceso de inspección de
Software. Para este fin, se realizó una búsqueda y
selección de sitios en Internet y lecturas relacionadas
con las inspecciones de software.

– Se estudió como participa las inspecciones de
software junto con los modelos de: "Modelo de Madurez de
Capacidad" [56] y el "Modelo de Madurez de Capacidad Integrado"
[62] [63]. Este estudio sirvió para la búsqueda de
las Listas de Comprobación adecuadas para el Proceso de
Software.

– Se revisó normas ISO para el ciclo de vida del
software, estableciendo una nueva clasificación de las
listas de comprobación.

– Se estableció un modelo de inspección de
software de acuerdo a la situación actual de tiene el
país, utilizando el análisis y reflexión de
los distintos modelos que se practican en el mundo sobre las
inspecciones de software.

– Se ha clasificado las listas de comprobación de
acuerdo a los distintos procesos y propiedades que tiene el
desarrollo de software.

– Se ha definido una arquitectura de software para la
aplicación que ha automatizado el proceso de
inspección de software propuesto.

– Se ha logro obtener un conocimiento aceptable sobre la
plataforma de desarrollo Visual Studio .Net de
Microsoft.

– Se realizó una validación del uso de las
listas de comprobación y el modelo de inspección en
la Universidad de Ciencias Informáticas y dentro del
Centro de Referencia de Ingeniería de Sistemas.

Se realizo un sitio Web, para la preparación de
los participantes en el modelo establecido en el presente trabajo
sobre las inspecciones de software.

CAPITULO 1

LA CALIDAD Y LAS
INSPECCIONES DE SOFTWARE

1.1 INTRODUCCIÓN

En el presente capitulo se presenta una breve
introducción a los conceptos, metas y objetivos del
aseguramiento de calidad de software, definiendo también,
las características que debe tomarse en cuenta para
satisfacer los distintos atributos de calidad descritos en el
capitulo. Estos atributos, serán rastreados durante el
desarrollo proyecto de software para lograr una mejora en el
proceso de software.

También, se presenta una introducción a
las inspecciones de software, presentando los objetivos que deben
lograse al aplicar este proceso. Conjuntamente se presenta, una
vista de los distintos modelos mas utilizados internacionalmente
para las inspecciones de software. Se explica los objetivos de
las listas de comprobación y como ayudan con el proceso de
inspección; se aclara, que con las inspecciones de
software se logra la detección de los defectos en un
artefacto desde el inicio del proyecto de software hasta el
final, por este motivo, se presenta una posible
clasificación de los defectos que se pueden encontrar,
hecha por José Javier Dolado Cosín [10], para
culminar se realiza una explicación de las reglas que
deben tomarse en cuenta al aplicar las listas de
comprobación y como dar una la valoración de una
lista.

Para culminar con el capitulo, se presenta un resumen de
las métricas de inspección de software y el
software existente en el mercado que automatiza el proceso de
inspección de software.

Este capitulo dará una idea general de la
importancia de las inspecciones de software en cualquier empresa
desarrolladora de software.

1.2 ASEGURAMIENTO DE LA CALIDAD DE
SOFTWARE (SOFTWARE QUALITY ASSURANCE – SQA)

El aseguramiento de Calidad es una actividad, para toda
empresa que desarrolla software y debe llevarla a cabo de una
manera limpia y correcta. Es un proceso de la ingeniería
de software, que se define como un "conjunto de acciones
planificadas y sistemáticas que son necesarias para
proporcionar la confianza adecuada en que un producto o servicio
cumpla con los requisitos dados sobre la calidad"
[46]. La medición y las métricas son un punto muy
importante en todo el proceso de software, como también,
el aseguramiento de calidad que se retroalimenta con los
resultados de las métricas. La obtención de
software con buena calidad implica la utilización de: un
modelo de proceso, una metodología de desarrollo, que
ayude a cumplir estrictamente el modelo de proceso seleccionado,
estos procesos son entre otros: procesos determinación de
requisitos, diseño, implementación y prueba, que
permiten estandarizar el conocimiento del trabajo, para lograr
una calificación adecuada en los "atributos de calidad
descritos por McCall" [13], políticas de control para
todas las fases de desarrollo y un proceso de medición
para el proceso de software.

El Aseguramiento de Calidad de Software engloba los
siguientes puntos:

– El mejoramiento de los métodos,
técnicas de análisis, diseño,
codificación y prueba [6].

– "Revisiones técnicas formales que
se aplican durante cada fase del proceso de desarrollo de
software" [6], que ayudan a detectar los defectos.

– "Utilización de estándares"
[47] durante el desarrollo.

– "Sistema de Métricas" [47], para
la retroalimentación de todas las personas

– Definir estrategias de prueba multiescala
[6];

– Control de la documentación del
software y de los cambios realizados [6];

– Un procedimiento que asegure, siempre que
sea posible, un ajuste a los estándares de desarrollo del
software. [6]

En el caso de la IEEE 1074, "este estándar
explica como el aseguramiento de calidad de software debe
apoyarse o relacionarse estrechamente son las siguientes
actividades:

– Verificación: Básicamente
revisiones y auditorias de configuración y
calidad.

– Validación: Todos los niveles y
fases de prueba de ejecución de software.

– Gestión de Configuración:
Como medio de control de los productos generados.

– Medición de software: Contempla la
necesidad de marcar objetivos y asociar métricas a los
objetivos. [46]"

La actividad del SQA, en empresas grandes, será
llevada por un grupo disciplinado, que deben seguir objetivos y
metas, que se describen en los epígrafes
siguientes.

1.2.1 OBJETIVOS DEL SQA

Entre los objetivos que persigue el SQA [55], para
delimitar su campo de acción y no confundir con otras
actividades se definen los siguientes:

– El SQA consiste en la revisión de los productos
y su documentación relacionada, para verificar su
contenido, corrección, confiabilidad y facilidad de
mantenimiento.

– La garantía de que un sistema cumpla las
especificaciones y los requisitos funcionales y no funcionales
para el desempeño deseado.

– Evitar la necesidad de realizar cambios
significativos, una vez que el producto se ha
terminado

– Desarrollar software al que sea
fácil mejorarlo.

– Garantizar que el proceso se lleve de acuerdo con los
estándares establecidos internacionalmente, para ello
toma, entre varias herramientas, las Inspecciones, para evaluar,
verificar y controlar los proyectos en ejecución, que
forma parte de los objetivos de las Revisiones y Técnicas
Formales, que "es una actividad del aseguramiento de calidad
llevada acabo por los ingenieros del software" [17].

Durante el trabajo, se aclara la función de las
Listas de Comprobación y el como contribuyen con los
objetivos que persigue el SQA, ya que éstas están
incluidas como una herramienta de las Revisiones y
Técnicas Formales que contribuyen al cumplimiento de los
requisitos.

1.2.2 METAS DEL SQA

El Modelo de Capacidad de Madurez (CMM) y Roger Pressman
definen para el SQA las siguientes metas que deben contribuir al
mejoramiento del proceso:

– Meta 1: Las actividades de aseguramiento de la calidad
del software (SQA) se planifican. [3] [17]

– Meta 2: Se verifica de una manera objetiva la
concordancia de los productos de software y de las actividades
con los estándares, procedimientos, y requisitos
aplicables. [3]

– Meta 3. Se posee la descripción del proceso de
software descrito y se actualiza sistemáticamente.
[17]

– Meta 4: Se revisan las actividades de
ingeniería de software para verificar el ajuste al proceso
de software definido. [17]

– Meta 5: Se realizan auditorias de los productos de
software designados para verificar el ajuste con los productos
definidos como parte del proceso de software. [17]

– Meta 6: Se asegura que las desviaciones del trabajo y
los productos del software se documenten y se manejen de acuerdo
con un procedimiento establecido. [17]

– Meta 7: Se registra lo que no se ajuste a los
requisitos y se informa a sus superiores. [17]

1.2.3 ACTIVIDADES DEL SQA

Según CMM el SQA debe realizar las
siguientes actividades [56][58]:

1. Un plan de aseguramiento de la calidad
del software es preparado para el proyecto de software siguiendo
un procedimiento documentado.

2. Las actividades del Grupo de
Aseguramiento de Calidad de Software (GSQA) se realizan de
acuerdo al plan de de aseguramiento de calidad.

3. El GSQA participa en la
preparación y revisión del plan del proyecto de
desarrollo de software, estándares, y
procedimientos.

4. El GSQA revisa las actividades de
ingeniería de software para verificar su conformidad de
cada una de ellas.

5. El GSQA audita los productos del trabajo
de software para verificar su conformidad.

6. El GSQA periódicamente reporta el
resultado de sus actividades al Grupo de
Ingeniería del Software (GIS).

7. Las desviaciones detectadas en las
actividades de software y en los productos del trabajo de
software son documentadas y manejadas siguiendo un procedimiento
documentado.

8. El GSQA conduce revisiones periódicas de sus
actividades y hallazgos con el cliente, de la forma más
apropiada.

1.3 CALIDAD DE SOFTWARE

El término calidad del software se interpreta de
diferentes maneras. Uno de los modelos más difundidos y
utilizados de calidad es debido a McCall (1977), "que especifica
una serie de atributos, con los cuales es posible tratar de
medirla. Sin embargo, existe una visión distinta, es la
definición de atributos juntamente con el usuario o
asociar la calidad a la ausencia de defectos en el transcurso del
desarrollo y vida del software. [10]" Tomar los atributos de
calidad de McCall, es comprometerse a realizar un seguimiento
durante el transcurso del desarrollo del proyecto de software a
estos atributos, además deben estar bien definidos en los
requisitos no funcionales y delimitar el limite de cada uno de
estos en el diseño de la Arquitectura de
Software.

Sin embargo, existen otros dos modelos que tratan,
también, de la calidad de software, uno es de Boehm (1978)
y de la ISO-9126, con algunas diferencias sobre el modelo de
McCall. En la Tabla 1.1 [7] se enumera los distintos atributos y
metas de los tres modelos.

EL PRESENTE TEXTO ES SOLO UNA SELECCION DEL TRABAJO
ORIGINAL.
PARA CONSULTAR LA MONOGRAFIA COMPLETA SELECCIONAR LA OPCION
DESCARGAR DEL MENU SUPERIOR.